Cherry-picked from PR #271 on the pp branch (3df1395,
"Gcc 14 clang tidy 21"), restricted to the toolchain registration parts.

The shared CI image (registry/prompp/ci-gcc-image:gcc-tools-${arch}) is built
only from the pp branch and now ships gcc-14 (debian-trixie). The release-0.7
build was still registering the g++-13 Bazel toolchain, whose
builtin_include_directories pointed at /usr/lib/gcc/{x86_64,aarch64}-linux-gnu/13
which no longer exist in the image; on top of that the linker was pulling
libstdc++_libbacktrace, which gcc-14 has folded into libstdc++exp.

This commit:
- registers cc_toolchain_for_g++-14_toolchain_{aarch64,x86_64} in
  pp/MODULE.bazel,
- drops the now-unused g++-13 cc_toolchain_suite / cc_toolchain / toolchain /
  cc_toolchain_config entries in pp/bazel/toolchain/BUILD,
- replaces -lstdc++_libbacktrace with -lstdc++exp in the default linker flags
  in pp/bazel/toolchain/cc_toolchain_config.bzl.

The clang-tidy / GOST-flag changes from PR #271 (which depend on PR #270
"GOST compile flags") are intentionally excluded because they were never
back-ported to release-0.7 and would pull in additional warnings that the
release branch has not been audited against.

Co-authored-by: Cursor <cursoragent@cursor.com>

Cherry-picked from PR #271 on the pp branch (file pp/third_party/patches/
quasis_crypto/0001-md5.hh.patch from 3df1395).

gcc-14 rejects the use of the built-in __is_trivially_copyable trait inside
a requires-clause ("error: use of built-in trait '__is_trivially_copyable'
in function signature; use library traits instead"). The updated patch:

- replaces __is_trivially_copyable(T) with std::is_trivially_copyable_v<T>
  in the requires-clauses of MD5::update overloads,
- adds the missing #pragma once and <bit>/<type_traits> includes,
- silences a -Wmaybe-uninitialized false positive around hasher.update().

Required to make pp/prometheus tests build under gcc-14.

Co-authored-by: Cursor <cursoragent@cursor.com>

Cherry-picked from PR #287 on the pp branch (c80d137)
for the production-code parts only.

GCC 14's libstdc++ uses sized-range fast paths in std::ranges::equal, which
breaks BareBones::GenericBitset because GenericBitset::size() returns the
allocated bit width, not ranges::distance(begin, end) (the set-bit count).
This caused runtime failures in pp/bare_bones/tests/bitset_tests.cpp
(BitsetFixture.random_access, BitsetConstructorsFixture.MoveConstructor /
MoveAssignment / MoveAssignmentNonEmpty) and in
pp/series_data/tests/querier/{instant_querier,querier}_tests.cpp where the
querier returns a Bitset that is then compared against an initializer_list.

Specialise std::ranges::disable_sized_range<GenericBitset<R>> = true to
restore element-wise comparison.

Also update pp/go/cppbridge/entrypoint.go cgo LDFLAGS:
  -lstdc++_libbacktrace      -> -lstdc++exp
  -l:libstdc++_libbacktrace.a -> -l:libstdc++exp.a
GCC 14 has folded libstdc++_libbacktrace into libstdc++exp; without this the
go-tests / build-go-bindings step fails to link.

Co-authored-by: Cursor <cursoragent@cursor.com>

set_const_labels was sorting label pointers with
  return a->name < b->name;
where a->name and b->name are const String*. This compares stack
addresses, not strings, so the resulting iteration order — and therefore
MetricDescriptor::id / dim_hash — depended on whatever order the local
String objects ended up at on the stack.

Under gcc-13 (and under gcc-14 on the pp branch with -fstack-protector-
strong from PR #270 GOST flags) the layout happened to match the
alphabetical order, so primitives_test/MetricDescriptorFixture.TestWithLabels
produced the expected 9433770049495071547 / 1413792954011449091. On
release-0.7 under plain gcc-14 the layout reverses, the labels are
hashed in the opposite order and the test fails with
8942707084255367343 / 18042764105132557107.

Compare the dereferenced strings instead. This matches what the Go
prometheus/client_golang side does (sort labels lexicographically by
name) and makes id/dim_hash deterministic across compilers / build
flags. The expected values in the test correspond to this alphabetical
order, so the test goes green.

MetricDescriptor::id is computed in the constructor and not persisted,
so the only effect of this change at runtime is that two metrics with
the same labels but constructed in different process invocations now
get the same id (which they already did on pp, just not on release-0.7
under the new compiler).

Co-authored-by: Cursor <cursoragent@cursor.com>

PR #317 (Jemalloc arena purge) added pp/metrics/jemalloc_metrics.h that
unconditionally references BareBones::jemalloc::FreeArenas::*, but the
FreeArenas struct itself is declared inside `#if JEMALLOC_AVAILABLE` in
bare_bones/jemalloc.h. JEMALLOC_AVAILABLE is set by preprocess.h only
when __has_include(<jemalloc/jemalloc.h>) succeeds.

pp/BUILD excludes @jemalloc from the entrypoint deps under
--config=asan:

    deps = [...] + select({
        "//bazel/toolchain:with_asan": [],
        "//conditions:default": ["@jemalloc"],
    })

so the asan build-entrypoint legs of build-go-bindings (matrix
ASAN=true) fail with "'BareBones::jemalloc::FreeArenas' has not been
declared" while compiling entrypoint/metrics.cpp.

Wrap the JemallocMetrics struct and its CreateMetricsPage registration
in `#if JEMALLOC_AVAILABLE` so the asan variant simply skips registering
arena-pool metrics (which have no source of truth in that build anyway,
since FreeArenas itself does not exist there).

The non-asan path is unaffected: @jemalloc is still a dep,
<jemalloc/jemalloc.h> is on the include path, JEMALLOC_AVAILABLE stays
1, JemallocMetrics is declared and registered as before.

Verified locally in the arm devcontainer: \`make compilation_mode=dbg
asan=true build-entrypoint\` now succeeds.

Co-authored-by: Cursor <cursoragent@cursor.com>

After PR #317 (Jemalloc arena purge), prompp_metrics_register() — invoked
from cppbridge.init() — globally registers a JemallocMetrics page with
three counters/gauges:

  prompp_common_jemalloc_arena_pool_releases_total
  prompp_common_jemalloc_arena_pool_released_bytes_total
  prompp_common_jemalloc_arena_pool_released_bytes_max

Iterating CppMetrics now always yields those three on top of whatever
test pages the suite creates, so TestCppMetricsSuite/{TestNoMetricPages,
TestOneMetricsPage,TestTwoMetricPages} fail with "should have N item(s),
but has N+3" on builds that include @jemalloc (i.e. the asan=false legs
of build-go-bindings → go-tests on PR #321). The asan=true builds were
already fine because the previous commit gates JemallocMetrics on
JEMALLOC_AVAILABLE.

Filter the well-known prompp_common_jemalloc_ prefix out of the suite's
getMetrics() helper so the assertions stay scoped to the per-test pages
the suite actually owns. The filter is a no-op when JemallocMetrics is
not registered (asan builds, and any future merge into pp where the page
does not exist yet), so behaviour does not change there.

Verified locally in the arm devcontainer:

  go test -count=1 -run TestCppMetricsSuite ./pp/go/cppbridge

passes all three subtests.

Co-authored-by: Cursor <cursoragent@cursor.com>